home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 3⁄30⁄90 / 0996-FindObject() and Fin-Mar90 < prev    next >
Encoding:
Text File  |  1990-03-30  |  4.8 KB  |  137 lines  |  [TEXT/GEOL]
  1. Item    7587233                         29-March-90        02:29PST
  2.  
  3. From:   POWERUP.ENG                     Power Up Software,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    FindObject() and FindValu
  8.  
  9. Attn:  MacApp.Tech$
  10. SentBy: James Plamondon
  11. Date   3/28/90
  12. Subject    FindObject() and FindValue(
  13. From   James Plamondon
  14. To  MacApp.Tech$
  15. CC Steve Friedrich
  16.  
  17. Subject:   FindObject() and FindValue()
  18. Gentlepersons,
  19.  
  20. I've been using TSortedLists a lot lately, and I've hit upon a small extension
  21. to the class that adds a lot of value to it — or so it seems to me.  I'd be
  22. interested in hearing your opinions.
  23.  
  24. Consider the function TSortedList.Search().  It accepts a function,
  25. TestItem(),  as an argument, and returns the first item encountered (in a
  26. binary search) for which TestItem() returns 0.  TestItem() is expected to be a
  27. function which accepts an object as its only argument, and which returns 0
  28. (kItem1EqualsItem2) if the given argument is "the right one."
  29.  
  30. So far, all well and good — except that I keep having to include the #$!@¡
  31. TestItem() function in my code, as a local function to the routine that calls
  32. Search().  This wastes my time, clutters my code, and increases the chance of
  33. error — specifically, that the various versions of TestItem() won't match.
  34.  
  35. I propose what I think is a simple (if not necessarily elegant) solution — the
  36. addition of three new functions to TSortedList.  Here are their interfaces:
  37.  
  38. FUNCTION TSortedList.FindObject(theObject: TObject): TObject;
  39.     { This function returns an object in the list which is the same as the
  40. given object,
  41.         according to Compare(). }
  42.  
  43. FUNCTION TSortedList.FindValue(valuePtr: Univ Ptr): TObject;
  44.     { This function returns an object in the list which has the same value as
  45. that pointed
  46.         to by the given pointer, according to CompareValue(). }
  47.  
  48. FUNCTION TSortedList.CompareValue(item: TObject; valuePtr: Univ Ptr):
  49. CompareResult;
  50.     { This function compares the given object to the value pointed to by the
  51. given pointer.
  52.         THIS FUNCTION MUST BE OVERRIDEN for it to make any sense. }
  53.  
  54. • Here are the implementations of FindObject() and FindValue() for
  55. TSortedList:
  56.  
  57. FUNCTION TSortedList.FindObject(theObject: TObject): TObject;
  58.         FUNCTION TestItem(item: TObject): CompareResult;
  59.             BEGIN
  60.             TestItem := Compare(item, theObject);
  61.             END;  { TestItem }
  62.  
  63.         BEGIN  { FindObject }
  64.         FindObject := Search(TestItem);
  65.         END;  { FindObject }
  66.  
  67. FUNCTION TSortedList.FindValue(valuePtr: Univ Ptr): TObject;  OVERRIDE;
  68.         FUNCTION TestItem(item: TObject): CompareResult;
  69.             BEGIN
  70.             TestItem := CompareValue(item, valuePtr);
  71.             END;  { TestItem }
  72.  
  73.         BEGIN  { FindValue }
  74.         FindValue := Search(TestItem);
  75.         END;  { FindValue }
  76.  
  77.  
  78. •  Here is an example of how these routines would be used, for a sorted list
  79. TFooList containing references to objects of class TFoo:
  80.  
  81. TFoo = OBJECT(TObject)
  82.     fValue: LONGINT;    { for example }
  83. END;  { TFoo }
  84.  
  85. TFooList = OBJECT(TSortedList)
  86.     FUNCTION TFooList.Compare(item1, item2: TObject): CompareResult;
  87.                 OVERRIDE;
  88.     FUNCTION TFooList.CompareValue(item: TObject; valuePtr: Univ Ptr):
  89. CompareResult;
  90.                 OVERRIDE;
  91. END;  { TFooList }
  92.  
  93. FUNCTION TFooList.Compare(item1, item2: TObject): CompareResult;
  94.                 OVERRIDE;
  95.     VAR
  96.         value:    LONGINT;
  97.  
  98.     BEGIN
  99.     value := TFoo(item2).fValue;
  100.     Compare := CompareValue(item1, @value);
  101.     END;  { Compare }
  102.  
  103. FUNCTION TFooList.CompareValue(item: TObject; valuePtr: Univ Ptr):
  104. CompareResult;
  105.                 OVERRIDE;
  106.     BEGIN
  107.     CompareValue := TFoo(item1).fValue - LongIntPtr(valuePtr)^;
  108.     END;  { CompareValue }
  109.  
  110.  
  111. •  Hark!  I can already hear the cries of outrage at the thought of passing an
  112. untyped pointer (valuePtr) around, and casting it to the "expected" type.  But
  113. that does not appear to me to be any worse than casting the type of the given
  114. objects from TObjects to TFoo's, which one must already do in a TList's
  115. Compare() method.
  116.  
  117. The advantage, of course, is that I can just override Compare() and
  118. CompareValue(), and I'm done.  I can use FindObject() and FindValue() instead
  119. of cluttering my code with a lot of friggin' TestItem()/Search() calls.
  120.  
  121. The only caveat that I can see is that the routine calling CompareValue()
  122. should make sure that it's not passing the address of an instance variable as
  123. valuePtr, since the comparison routine might be in a different segment (and
  124. thus move memory, making the address invalid).  Since valuePtr is a universal
  125. pointer, it can contain a reference to just about anything.
  126.  
  127. So — whadduya think?  Would this be a useful extension to TSortedList, or is
  128. this yet another sign of a warped mind and a twisted way of looking at the
  129. world?
  130.  
  131. Looking forward to your responses,  I remain
  132.  
  133. Yours,
  134.  
  135. James Plamondon
  136.  
  137.